EC2でMicrosoft Officeを使うのはライセンス上一筋縄ではいかない話

EC2でMicrosoft Officeを使うのはライセンス上一筋縄ではいかない話

Clock Icon2022.12.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。

先日Microsoft Office LTSC入りAMIが提供され実際に試してみた記事を公開しました。

https://dev.classmethod.jp/articles/how-to-use-microsoft-office-ltsc-ami-202212/

AMIが公開される以前から「EC2でMicrosoft Officeを使いたい。(EC2でExcelを使いたい、などの派生を含む)」という相談をよく受けていたのですが、ライセンス上の問題によりEC2にMicrosoft Officeを導入するのは一筋縄ではいきませんでした。

本記事ではそのへんのライセンス周りの難しさについて注意喚起の意味も込めて解説します。

免責事項

ライセンスの話をするのでいつも通り免責事項を最初に。

【重要】まずはAmazon WorkSpacesで代替できないか検討してください

単純にAWS環境上でMicrosoft Officeを使いたいという事であれば、まずはAmazon WorkSpacesの利用を検討してください。
これはOffice入りAMIが公開された今でも変わらないと私は考えています。

https://aws.amazon.com/jp/workspaces/

Amazon WorkSpacesではMicrosoft Office Professional Plusをバンドル済みのマシンイメージが提供されておりライセンス上の懸念を一切気にすることなく利用することができます。

それでもEC2でMicrosoft Officeを使いたい方へ

それでもEC2でOfficeを使いたい場合Office入りAMIを使ってください。
Office入りAMIを使う際はライセンス管理のために、

  • ユーザー認証にAWS Managed Microsoft ADが必須
  • ライセンス管理のためにAWS License Managerの利用が必須
  • OfficeライセンスアクティベーションのためにVPC Endpointが必須
  • Active DirectoryとのDNS連携のためにRoute 53 Resolver Outbound Endpointが原則必須

と多くの前提条件があります。
これらの条件をクリアしてでもEC2を導入すべきかを慎重に考えることを推奨します。

Office入りAMIが提供される以前はSPLAのService ProviderからOffice入りの環境を提供してもらうしかありませんでした。
一応現在もこの方式は使えるのですが2025年9月30日まで期限付きとなります。2025年9月30日以後は利用不可なので今から導入するのは決しておススメできません。

https://dev.classmethod.jp/articles/personal-opinion-for-microsoft-spla-license-revision-2022/

注意 : 自分でOfficeをインストールしないでください

Microsoft Officeライセンスの複雑さ

Microsoft製品はそれぞれ固有のライセンス条項があり、Officeも独自のライセンスの元で提供されています。

Officeの販売形態としては大きく

  • 買い切り版 : リテール版やボリュームライセンス版Office(Office LTSC 他) など
  • サブスクリプション版 : Microsoft 365 Apps(旧:Office 365 ProPlus)など

の2形態ありますが、どちらも個人のクライアント端末か組織が保有するハードウェア環境(要はオンプレ環境)でのみインストールして利用可能です。
クラウド環境などのサービス事業者がハードウェアを所有する環境には原則として[1]持ち込めません。

クラウド環境でOfficeを利用するにはAzure、Microsoftが認めたホスティング事業者(QMTH)、SPLA Service Providerによるサービスとしての提供のいずれかである必要があります。

細かい話はWindows Virtual Desktop ライセンスガイドに記載されていますのでご一読ください。

SPLAライセンスガイド P28

(Windows Virtual Desktop ライセンスガイド P28より引用)

AWSの場合

上記の表に関してAWS環境においては以下の通りとなります。

環境 対象ソフトウェア AWSでの利用可否
占有ホスト (Dedicated Hosts) Office Professional Plus OK : AWSサービス利用 or SPLA提供であれば可能
占有ホスト (Dedicated Hosts) Microsoft 365 Apps NG : AWSでは利用不可
共有ホスト (通常のEC2) Office Professional Plus OK : AWSサービス利用 or SPLA提供であれば可能
共有ホスト (通常のEC2) Microsoft 365 Apps NG : AWSでは利用不可

雑に言ってしまえば、サブスクリプション版OfficeはAWSで一切利用不可、買い切り版OfficeであればAWS公式サービスを使うか2025年9月30日までならSPLA提供のものを使うことができる、といった感じです。

ユーザーが購入したOfficeをAWSに持ち込むことはどちらの場合も出来ません。BYOL不可です。
ただし、ひとつだけ例外があり、2019年10月1日以前に購入した製品であれば占有ホストでのみ購入したバージョンのOfficeをBYOLすることが可能です。
これは2019年10月1日を境にライセンス上の占有ホストの扱いが異なるためです。

https://dev.classmethod.jp/articles/microsoft-updated-licensing-rights-for-dedicated-cloud/

SPLAライセンスガイド P30

(Windows Virtual Desktop ライセンスガイド P30より引用。ピンク字の強調は筆者が加筆)

とはいえ、この場合Officeのバージョンアップは不可ですので、2022年も終わりつつある今現在では決しておススメできる方法ではありません。

Officeのサーバーサイドオートメーション

Officeを利用可能な環境の時点で十分めんどうな感じではありますが、Officeの利用形態においても問題があります。

私のこれまでの経験上EC2でOfficeを利用する用途としてバッチ処理でOfficeを使うといった「サーバーサイドオートメーション」の要望が多いのですが、Officeのサーバーサイドオートメーションはそれ自体が多くの問題をはらんでいます。

そもそもOfficeはクライアント環境において対話的に利用することを前提としたソフトウェアであり、非対話的に利用するのはサポート外です。

Microsoftでは、無人の非対話型クライアント アプリケーションまたはコンポーネント (ASP、ASP.NET、DCOM、NT サービスを含む) から Office アプリケーションをMicrosoft自動化することは現在推奨されておらず、サポートされていません。この環境で Office を実行すると、Office が不安定な動作やデッドロックを発生する可能性があるためです。

ライセンス面でも

技術的な問題とは別に、ライセンスの問題も考慮する必要があります。 現在のライセンス ガイドラインでは、クライアントにライセンス認証済みの Office がインストールされている場合を除き、クライアント要求を処理するサーバー上で Office アプリケーションを使用することは禁じられています。

といった形で全ての利用クライアントにOfficeが必要ですのでご注意ください。

追記 : 最近のOfficeは元々サーバーサイドオートメーションが禁止されている

どのバージョンからだったか覚えていないんですが、最近のOfficeだとはじめから規約でサーバーサイドオートメーションが禁止されています。[2]

一例として上記ページからOffice 2016のライセンス条項を確認してみると、「2. インストールおよび使用権」の「c. 制限」において

c. 制限。製造業者またはインストール業者、およびマイクロソフトは、本ライセンス条項において明示的に許諾されていない権利 (知的財産に関する法律に基づく権利など) をすべて留保します。たとえば、このライセンスは、次の行為に関してお客様にいかなる権利も与えるものではなく、お客様は次の行為を行うことはできません。

(v) 本ソフトウェアを商業的ホスティング用のサーバーソフトウェアとして使用すること、本ソフトウェアをネットワークを介して複数のユーザーが同時に使用できるようにすること、本ソフトウェアをサーバーにインストールしてユーザーがリモートアクセスできるようにすること、または本ソフトウェアをリモートユーザーのみが使用する目的でデバイスにインストールすること。

という形でサーバーソフトウェアとしての利用を禁止する記述[3]が存在します。

より新しいバージョンのOfficeでも同様ですので現在は「そもそもサーバーサイドオートメーションは不可」と認識していただくのが良いと思います。

リモートデスクトップ接続

EC2でOfficeを使う場合、対象のインスタンスにはリモートデスクトップ接続でログインする必要があります。

Windows Serverのデフォルトでは「管理用途に限りデフォルトで同時2セッションまでRDP接続可能」となっていますが、Officeの利用は基本的に管理用途には当てはまりません。
このためAWSが提供するOffice入りAMIの利用においてもRemote Desktop Service SAL(RDS SAL)のサブスクライブが必須となっています。

加えてユーザーライセンスのRDS CAL/SALを管理するにはActive Directory環境が必要です。
Office入りAMIを利用する際にAWS Managed Microsoft ADを使うのはこういった事情があります。[4]

利用者から見れば「単純にOfficeを使いたい」だけかもしれませんが、Microsoftライセンスの都合重厚な環境が必要となります。

まとめ

以上となります。

AWSでMicrosoft Officeを使うにはライセンス面および環境面で多くの面倒ごとがあるのがご理解いただけたと思います。
個人的には「AWSではMicrosoft Officeを使わない」のが一番お勧めできますが、どうしても必要な場合はAWS公式のサービスを使う様にしてください。

この記事は最初に書こうと思った時から1年くらい寝かせてしまっていたのですが[5]、先日のSPLAライセンス改定の話も出てきたので気合いで再構成して書き直しました。

Microsoftライセンスのつらみが少しでも共有できれば幸いです。

脚注
  1. あくまで原則です。Microsoft 365 Appsの共有コンピューターライセンス認証(SCA)といった例外があるのがMicrosoftライセンスの厄介なところです... ↩︎

  2. 昔のOfficeには禁止の規約が無かった記憶がありますが、自分の記憶がどこまで正しいかちょっと自信がありません... ↩︎

  3. 「商業的ホスティング用」でなければ良いのでは?という反論はあろうかと思いますが、その点については気になる方が個別にMicrosoftに問い合わせて確認してください ↩︎

  4. それ以外にAWS独自の制限を入れるためでもありますがここでは割愛します ↩︎

  5. Microsoftライセンスは本当につらいんです...メンタルに大ダメージがあるのです... ↩︎

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.